Peripheral systems consist of peripheral devices, peripheral clients and peripheral servers. A peripheral device may include a printer, a scanner, or multi-function devices. A peripheral client is a computer that makes use of the peripheral device. A peripheral server is a computer that makes a peripheral device and its services available to a peripheral client, generally over a network or a communication interconnection.
Managing a peripheral system involves the configuring of peripheral devices, obtaining their status and receiving events from these peripheral devices. The capabilities of peripheral devices vary widely. Communication protocols used for interacting with the devices also vary widely. Software that manages interactions between peripheral clients and peripheral devices must accommodate this variety of capabilities and protocols. Further, vendors constantly ship new models of peripherals, peripheral servers and peripheral clients. Software for managing these changes must be constantly revised to support the new devices and new device features. All of this significantly increases the complexity of software used to manage a peripheral system.
Prior art programs that enabled a peripheral client to access the capabilities of a peripheral device and data regarding functions performed by the peripheral device, have caused such data to be stored in a file associated with an application program running on the peripheral client. For instance, one prior art technique for enabling peripheral clients/peripheral device communication utilized a get/set interface with a collection of objects types. To retrieve information about a peripheral device, the application program would issue a "get" request for a desired object type. In response, peripheral abstraction codes would retrieve the requested information from the peripheral device and send it back to the caller in a data buffer. Likewise, if the application program needed to configure a setting in the peripheral device, it would enter the setting data into a data buffer and issue a set request to an appropriate object type, passing the buffer thereto.
In order for such prior art systems to provide enhanced performance, the results of many of the get and set requests were cached in a database associated with the application program, for future use. If a subsequent request was made for data that had already been previously retrieved and cached, the new request was serviced from the cache in the application (rather than over the network from the device itself). Avoiding additional network traffic provided a significant performance advantage, versus not having the data cached at all.
The prior art solution, to implement the cache model, stored a copy of the data buffer in the application's database, when the object was first requested. Then, if the object was requested again, the copy of the stored buffer was returned to the caller. This function was enabled by simply routing all object requests through the database first.
Accordingly, it is an object of this invention to provide an improved procedures for the management of device communications in a peripheral system.
It is another object of this invention to separate peripheral status and capability data from application programs so as to isolate the application programs from change requirements when peripheral devices are added or modified.
It is still another object of this invention to utilize the benefits provided by object-oriented programming languages to enable improved peripheral system management.